Skip to content

chore: drop the unused repository-url and repository-tag keys - #33

Merged
tdudgeon merged 1 commit into
mainfrom
fix/drop-unused-repository-keys
Aug 13, 2026
Merged

chore: drop the unused repository-url and repository-tag keys#33
tdudgeon merged 1 commit into
mainfrom
fix/drop-unused-repository-keys

Conversation

@tdudgeon

Copy link
Copy Markdown
Collaborator

moldb.yaml was the only Job Definition in the ecosystem carrying these two
top-level keys.

Nothing reads them

Zero hits across the job decoder, the job operator, the job utilities and the
job tester. They are not in the schema, not in the documentation, and not in any
other definition.

Both values were wrong from the day they were written

Key Value Reality
repository-url .../virtual-screening/moldb.yaml 404 — the real path is /blob/main/data-manager/moldb.yaml
repository-tag '1.0.0' Tag 1.0.0 is from 2021-06-02; moldb.yaml was created 2022-10-05, so the file does not exist at the tag it names

They arrived with the file in d16c539 ("more complete moldb workflows",
2022-10-05) and were never touched again. This is boilerplate that was never
correct and never consumed — not a convention that lost its tooling.

On the intent

The idea behind them — recording the fixed point a definition came from — is
sound, and was reaching for what
squonk2-jobs#43
later concluded. But it is met properly by loading a manifest from a repository
tag
; a self-referential field inside the definition can only drift from the
truth, as both of these did within months.

Impact

None. No Job behaviour changes and no Job version is affected — these are
file-level keys that nothing read.

Why now

This clears the live example behind hole 1 in
docs/schema-coverage.md
— the last of three blockers preventing the schema's remaining objects from
setting additionalProperties: false.

With this merged, simulating the closure of all three remaining holes (root
object, job, test-checks-output) against every Job Definition in the
ecosystem produces zero errors. A companion decoder PR follows.

Verification

jote 0.14.0 with decoder 2.7.0 — manifest-moldb.yaml passes 12/12.

Refs InformaticsMatters/squonk2-jobs#8.

🤖 Generated with Claude Code

moldb.yaml was the only Job Definition in the ecosystem carrying these two
top-level keys, and nothing has ever read them - no hits in the job decoder,
the job operator, the job utilities or the job tester.

Both values were also wrong from the day they were written:

- repository-url pointed at
  https://github.com/InformaticsMatters/virtual-screening/moldb.yaml, which
  404s. The real path is /blob/main/data-manager/moldb.yaml.
- repository-tag claimed '1.0.0', a tag from 2021-06-02. moldb.yaml was not
  created until 2022-10-05, so the file does not exist at the tag it names.

They arrived with the file in d16c539 ("more complete moldb workflows",
2022-10-05) and were never touched again. This is boilerplate that was never
correct and never consumed, not a convention that lost its tooling.

The intent behind them - recording the fixed point a definition came from -
is sound, and is met properly by loading a manifest from a repository tag
(see docs/versioning.md in the umbrella repository). A self-referential
field inside the definition can only drift from the truth, as these two did.

No Job behaviour changes and no Job version is affected: these are file-level
keys that nothing read.

This clears the live example behind hole 1 in docs/schema-coverage.md, the
last of the three blockers preventing the schema's remaining objects from
setting 'additionalProperties: false'.

Verified with jote 0.14.0 against decoder 2.7.0: manifest-moldb.yaml passes
12/12.

Refs InformaticsMatters/squonk2-jobs#8.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tdudgeon added a commit to InformaticsMatters/squonk2-data-manager-job-decoder that referenced this pull request Aug 13, 2026
Completes the work started in #4. Three object definitions still accepted
unknown keys, so anything misplaced or misspelled inside them validated
silently. They were the last three in the schema without
'additionalProperties: false':

- the top-level object
- 'job'
- 'test-checks-output'

Each had a real cost. The top-level hole let 'repository-url' and
'repository-tag' sit in a Job Definition for four years - read by nothing,
and both values wrong (InformaticsMatters/virtual-screening#33). The 'job'
hole let an 'options' block sit directly on a Job rather than under
'variables', where it was silently ignored, leaving that Job impossible to
run from the Data Manager at all (InformaticsMatters/virtual-screening#32).

Adds the first two fixtures to example-definitions/bad, which was empty of
YAML, so both closures are covered by test_bad_example_definitions.

Verified: all 72 tests pass, the four 'good' fixtures still validate, and
every one of the 18 Job Definitions across the Job repositories validates
against the tightened schema with zero errors - the three offending Jobs
having been corrected first.

Note for the release: like 2.7.0 this rejects definitions that previously
passed. Consumers pinning the decoder control when they take it; those
resolving it transitively do not, so it is worth clear release notes.

Refs InformaticsMatters/squonk2-jobs#8.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
@tdudgeon
tdudgeon merged commit b912485 into main Aug 13, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant